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SUMMARY 

The digital control portion of a low-cost 406-MHz COSPAS/SARSAT emergency 
beacon has been designed and breadboarded at the NASA Lewis Research Center. 
This report discusses the requirements and design tradeoffs of the digital con- 
troller and describes the hardware and software design. The detailed hardware 
and software design is available to United States citizens or companies. 


INTRODUCTION 

In the 1970's, NASA began experimenting with Doppler tracking for locating 
terrestrial transmissions. In 1976, the search and rescue satellite program 
became an international effort involving the United States, Canada, and France. 
By 1980, the Soviet Union became involved, thus creating the COSPAS^ /SARSAT^ 
program. This program is divided into two emergency beacon detection systems: 
one system designed for interaction with aircraft and the other system designed 
for interaction with satellites. Both systems are currently operational 
(ref. 1). 

Emergency transmitters designed for interaction with aircraft were devel- 
oped first. These transmitters have also been used with satellites. A beacon 
with a characteristic audio signal transmitted at 121.5 or 243 MHz can be 
located to within 20 km (12 mi). However, these emergency transmitters must 
be within a 3220-km (2000-mi) radius of a ground terminal in order to be 
received. 

A major problem with the 121. 5/243-MHz transmitters has been the large 
number of "false alarms" caused by unintentional activation and by equipment 
failure. Presently, the only way to track down false alarms is to send out a 
rescue force to investigate. This can become quite expensive. 

A second system, using 406-MHz transmission, has been designed specifi- 
cally for use with satellites. This system provides the following improvements 
over the 121 .5/243-MHz system: global monitoring, location determination to 

within 5 km (3.1 miles), and a beacon-specific message. Because each beacon- 
specific message contains a user identification code, false alarms can be 
quickly tracked by contacting the beacon user. If the user can be contacted, 
the transmission is obviously a false alarm. 


IcOSPAS is the Space System for Search of Vessels in Distress (transla- 
tion from Russian) . 

^SARSAT is the Search and Rescue Satellite-Aided Tracking System. 
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Three classes of 406-MHz emergency beacons exist: the emergency locator 

transmitters (ELT's), emergency position indicating radio beacons (EPIRB's), 
and personal locator beacons (PLB's). ELT's and EPIRB's are readily available. 
PLB's are available only on a limited basis. Presently, each class of emer- 
gency beacon must meet the same operational and environmental specifications. 
ELT's are packaged for use on aircraft (i.e., manual or crash activation), 
EPIRB's are packaged for use on maritime vessels (i.e., waterproof, floats, 
manual or water activation), and PLB's are packaged for use by campers, back- 
packers, and recreational boaters (i.e., small and easy to carry). 

NASA is attempting to stimulate technological advances in a number of 
areas in order to reduce dramatically the cost of the 406-MHz beacons. Since 
April 1986 the minimum cost for an EPIRB or ELT has been approximately US$1500. 
This is considered too high to mandate that all commercial shipping, large rec- 
reational boats, and aircraft carry 406-MHz beacons. NASA would like to bring 
the cost down to US$300 to US$500 per unit in production quantities. 

The 406-MHz beacon can be divided into seven subsystems: digital control- 

ler, ultrastable oscillator, oscillator-multiplier chain, modulator, amplifier, 
antenna, and battery (fig. 1). The items that require technology advancements 
in order to meet the international specifications and remain low in cost are 
the oscillator, modulator, amplifier, and battery. The digital controller has 
been developed using present technology. A discussion of the digital control- 
ler design follows. 


REQUIREMENTS 

The following are general requirements for the 406-MHz beacon digital con- 
troller. It must be able to 

(1) Control power to the oscillator and amplifier 

(2) Turn the 121.5-MHz beacon 0N/0FF 

(3) Generate both long and short messages with the characteristics 
illustrated in tables I to III 

(4) Generate 21 Bose-Chaudhuri-Hocquenghem (BCH) error-correcting bits 
by using a BCH (82,61) code 

(5) Transmit the carrier for 160 msec ±1 percent 

(6) Transmit the message in a Biphase-L format at a bit rate of 400 bps 
±1 percent (fig. 2) 

(7) Transmit the message every 50 sec with a jitter of ±2.5 sec to avoid 
the synchronization of any two transmitters 

(8) Provide asynchronous communication capability through an RS-232- 
type port 

(9) Provide self-test capability 
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(10) Determine whether the beacon was activated manually or automatically 

(11) Determine emergency code (tables IV and V) 

Detailed requirements for the 406-MHz emergency beacon are described in 
reference 2. 


HARDWARE DESIGN 

The general guidelines for the overall beacon, including the digital 
controller, were low cost, low parts count, and, if possible, low power, 
because the beacon is powered by a battery. Upon reviewing the operational 
requirements and formulating a sales and licensing scenario, a simple three- 
chip design was developed using an 80C51 microcontroller, a 256x4 PROM, and a 
1 Kx4 PROM (fig. 3). 

The 80C51 microcontroller has 4K of on-board PROM, 128 bytes of on-board 
RAM, two internal timers, and a transmit and receive port for asynchronous com- 
munications. It also meets the 406-MHz beacon temperature requirements. The 
4K of PROM and 128 bytes of RAM are more than adequate to hold the software. 

One timer is used to generate the transmission bit rate while the other timer 
generates the asynchronous communication baud rate. The 80C51 provides the 
necessary signals for reading the two PROM's as well as providing up to 24 
input/output ports and 2 external interrupts (figs. 4 and 5, and ref. 3). 

The 256x4 PROM is used for storing beacon-specific data (i.e., user ID, 
country code, etc.). Having the beacon-specific information stored on a PROM 
allows for easy, inexpensive programming of individual beacons. 

The 1Kx4 PROM is used to encode switch settings which specify the emer- 
gency code. Having the i’ROM encode the switch settings allows the switch to 
be simple and inexpensive, thus increasing the reliability of the overall cir- 
cuit. Also, by using a PROM, the same circuit can generate any 4-bit emergency 
code. 


In order to eliminate the need for extra integrated circuits (IC's), the 
hardware design has an unusual addressing implementation. In order to elimi- 
nate the need for multiplexing the PROM enable signal, both PROM's are always 
read together. Each PROM uses a 4-bit-wide data bus. Two PROM's are put in 
parallel to form an 8-bit data bus compatible with the 80C51 . The 80C51 
addressing system expects the lower 8 of 16 address bits to be latched during 
each read/write cycle because the lower 8 address bits and the data bus are 
multiplexed. In order to eliminate an IC for latching, the beacon-specific 
data PROM is addressed using the upper 8 address bits. 


SOFTWARE DESIGN 

The main program consists of an interrupt handling routine and the follow- 
ing major modules: initialization of the CPU, RS— 232 communications, message 

generation, Biphase-L transmission, and jitter delay (fig. 6). The main pro- 
gram and the RS-232 communication module are written in a high-level language 
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(Intel's PLM). Because of the extremely detailed byte and bit manipulation 
involved in the remaining modules, they are written in assembly language. 


COMMUNICATION MODULE 

The communication module is written for asynchronous RS-232 communications 
at 110 baud. In order to simplify the proof of concept software, all critical 
timing modules were written around a machine cycle time of 1 msec, which 
requires a 12-MHz crystal (ref. 3>. Because the communication module was 
implemented last and all previous timing was based on a 12-MHz crystal, the 
110-baud rate was the only standard rate that could be generated by the 80C51 
baud-rate generator circuits. The baud rate could easily be modified by chang- 
ing the oscillator and slightly modifying the software. A commercially manu- 
factured 406-MHz emergency beacon would probably operate at 1200, 4800, or 
9600 baud (refs. 4 to 6). 

The following are valid commands: ECHO, TEST, RUN, and LONGITUDE and 

LATITUDE. The ECHO command causes the ECHO flag bit to toggle. The ECHO bit 
indicates whether or not the system should echo characters back to the terminal 
or the computer. ECHO is used mainly to debug the communications and to allow 
for operation with a terminal that does not echo characters to itself. The RUN 
command causes the RUN flag bit to be set. A RUN bit, when set, terminates the 
communications routine allowing message generation and transmission to begin. 
The TEST command initiates three separate tests: the 80C51 test, the data PROM 

test, and the switch PROM test. The 80C51 and data PROM tests are checksum 
tests. A calculated checksum is compared with the expected checksum that is 
stored in the last location of the 80C51 ROM and the last two locations of the 
data PROM. If the test is successful, a test flag bit is set. The switch data 
PROM is tested by placing the switch in the test position and comparing the 
value read with the expected value. A checksum test cannot be performed on the 
switch PROM because this PROM cannot be addressed from the 80C51 . Upon comple- 
tion of the test, the 80C51 returns an ASCII value to the computer or terminal 
(table VI). The LONGITUDE and LATITUDE command is used to enter longitude and 
latitude information into the 80C51 (table VII). Execution of the LONGITUDE 
and LATITUDE command causes the longitude and latitude information to be prop- 
erly formatted and stored in the long message portion of the 80C51 RAM. 

Use of the RS-232 communication port requires a 5-V power line to mini- 
mize the drain on the beacon's battery. Immediately after the beacon is 
powered on, the external power input is tested. If external power is being 
supplied, the communication module is called; otherwise, the communication mod- 
ule is bypassed and message generation and transmission begin. The two ways of 
exiting the communication loop are by executing a RUN command or by removing 
the external power. When the external power (RS-232 connector) is removed, 
the battery power takes over. Removing the external power causes an external 
interrupt which sets the RUN flag bit, thereby causing an exit from the commu- 
nication module. 


MESSAGE GENERATOR MODULE 

The message generator module performs two major functions: first, it 

generates the 21 BCH error-correcting bits, and second, it places the beacon- 
specific information and emergency code information into the proper locations 
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within the first 112 bits of the message. The BCH encoding routine is per- 
formed before the full 112-bit message is formatted. This is done to conserve 
RAM by utilizing bits 1 to 24 for temporary storage. After the 21 BCH encod- 
ing bits are generated, the short message is easily constructed using general 
assembly code commands (i.e., SHIFT, ROTATE, AND, OR, XOR, and others). 

The BCH (82,61) is a shortened form of the BCH (127,106) triple error- 
correcting code (refs. 7 to 9). Since the BCH code is a cyclical code, it can 
be easily implemented in hardware by using a 21-bit shift register (fig. 7) or 
in software by using software-implemented shift registers. Shift registers of 
any length can be generated in software by using ROTATE with CARRY commands 
acting on previously reserved contiguous bytes of RAM. The BCH (82,61) encod- 
ing algorithm (fig. 8) uses the following two software-implemented shift regis- 
ters: a 61-bit data register and a 21-bit code word register. Before entering 

the BCH encoding loop, a storage register is initialized to a count of 62. The 
loop counter is decremented and tested for zero. After all 61 data bits have 
passed through the encoder, the loop counter is zero, signifying that the en- 
coding is complete. If the loop counter is not zero, the information in the 
data register is rotated so that bit 0 becomes bit 60, bit 1 becomes bit 0, 
etc. After rotating the data register, data bit 60 and code bit 20 are 
exclusive-ORed and saved as a temporary code bit. The code register is shifted 
so that code bit 19 becomes code bit 20, code bit 18 becomes code bit 19, etc. 
The temporary code bit becomes code bit 0. Since 0 exclusive-ORed with any 
constant is that constant, if the temporary code bit is 0, then program execu- 
tion returns to the beginning of the BCH encoding loop. If the temporary code 
bit is 1, the 21-bit code word is exclusive-ORed with the BCH encoding polyno- 
mial before returning to the beginning of the BCH encoding loop. Table VIII 
shows an example of the BCH encoding algorithm for the three data bits. 


BIPHASE-L TRANSMISSION MODULE 

The Biphase-L transmission module controls three modulator signals that 
determine the phase of the transmit RF signal: 0 rad for the carrier, 

+1.1 rad, and -1.1 rad (fig. 2). The module is composed of a message rotation 
loop and four separate delay loops that account for carrier and bit rate timing 
adjustments (fig. 9). The program first tests for a long or short message for- 
mat. If a short message is to be transmitted, the end-of-message address is 
set for a 14-byte message, and the loop counter value for the third delay loop 
is set to compensate for rotation of a 14-byte message. If a long message is 
to be transmitted, the end-of-message address is set for an 18-byte message, 
and the loop counter value for the third delay loop is set to compensate for 
rotation of an 18-byte message. After initializing the end-of-message address 
and the loop counter value used in the third delay loop, the carrier is turned 
ON, and the first delay loop is executed. This delay loop adjusts for 160 msec 
minus the amount of time it takes to rotate the message and begin the Biphase-L 
transmission loop. Note that the ±1 percent variance in the carrier specifica- 
tion means the delay loop does not have to compensate for long or short message 
rotation. The message transmission loop is entered while the carrier is still 
being transmitted. The message transmission loop begins by testing to see if 
the entire message has been transmitted. If it has not, the entire message is 
rotated so that the last message bit becomes the second last message, continu- 
ing until the second message bit becomes the first message bit, and the first 
message bit becomes the last message bit. The first message bit is also trans- 
mitted for half the bit time (1.250 msec) by setting either the +1.1- or the 
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-1.1-rad control line, depending on whether the first message bit is 1 or 0, 
respectively. The timing for this is controlled by the second delay loop. The 
Biphase-L transmission is implemented by toggling the +1.1- and -1.1-rad con- 
trol lines and transmitting the second half of the first message bit. The 
third delay loop is executed next. This delay loop compensates for the 
1.250 msec transmission time minus the time it takes to test for the end of 
the message and to rotate through either the long or short message. Note that 
both the long and the short message must be accounted for in the third delay 
loop because there is not enough margin in the transmission time specifications 
to ignore the extra four rotations necessary for long messages. After the 
third delay loop is completed, the program returns to the beginning of the 
transmission loop where the end-of-message test is executed. Even though the 
end-of-message test may indicate that the entire message was transmitted, the 
last half of the last bit of the message is still being transmitted. There- 
fore, a fourth delay loop is necessary to compensate for the 1.250 msec minus 
the end-of-message test and the time it takes to terminate transmission. 


JITTER DELAY MODULE 

The jitter delay module (fig. 10) terminates message transmission, con- 
trols the power to the amplifier, modulator, and homing beacon (if one exists), 
and creates a 47.5- to 52.5-sec delay between message transmissions. Upon 
entering the jitter delay module, the message transmission is terminated, the 
amplifier and modulator power are both turned OFF, and the homing beacon is 
turned ON. The amplifier and modulator power are turned ON and the homing 
beacon is turned OFF before exiting this module. The 47.5- to 52.5-sec delay 
is created by generating a 47.5-sec delay and a 0- to 5-sec delay using the 
routine shown in figure 11. The 0- to 5-sec random jitter is created by using 
an address pointer to sequence from byte 4 through 14 of the transmission mes- 
sage (the beacon-specific information) and loading the timing-loop counter with 
the byte of information pointed to by the address pointer. 


ADDITIONAL COMMENTS 

Since the present 406-MHz beacon batteries are sized to accommodate the 
power drain of the RF amplifier, the power drain of the digital circuits is 
insignificant. Because this may not be the case in the future, the digital 
controller is implemented with power conservation in mind. All timing delays 
are implemented using the internal timers available on the 80C51 and the 
software-initiated "idle mode" capability of the 80C51 . When in the idle mode, 
the 80C51 CPU is inactive while at the same time the on-chip peripherals and 
counters remain active. The idle mode terminates when any enabled interrupt is 
received or by a hardware reset. In the case of the timing delays, the idle 
mode terminates when the internal counter overflows. A detailed discussion of 
the idle mode is available from reference 3. 

The 406-MHz distress beacon software design has been written specifically 
for the User Protocol message format (table III). The software can easily be 
modified to accommodate the Maritime/Location protocol (table II) with almost 
all modification residing in the communication routines. 

For a number of reasons, it appears rather impractical that the communica- 
tion routines would be used in the present 406-MHz environment when the User 
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Protocol format is used. First, the communication routines are necessary only 
when the long message format is used. For the User Protocol, the long message 
contains longitude and latitude information that is redundant information 
because the longitude and latitude are being determined by the satellite 
through the use of Doppler tracking. Second, if the capability exists to 
input longitude and latitude information into an EPIRB or ELT over an asynchro- 
nous communication link during an emergency, the capability most probably also 
exists to simply radio for help. Third, EPIRB * s , in particular, would be much 
more expensive to manufacture when asynchronous communication capability is 
included. The increased expense would be associated almost entirely with the 
connector. The connector would have to be reliable, withstand corrosion, and 
be able to separate easily and reliably from the EPIRB when the vessel is sink- 
ing. Also, some additional circuitry would be required in order to switch 
between external power and battery power. 

An EPIRB that uses the Maritime/Locator Protocol must have asynchronous 
communication capability because the user-specific data portion of the message 
contains the longitude and latitude information, and the long message portion 
of the message contains the time, course, and speed of the vessel. All of this 
information must be provided from an external source through the asynchronous 
communication port. 

In the future, geostationary satellites may be used for detection of 
emergency beacons. The advantage of the geostationary satellites over the 
presently used polar-orbiting satellites is that geostationary satellites offer 
continuous immediate global coverage, whereas polar-orbiting satellites receive 
emergency transmission for only 15 min every few hours. If geostationary 
satellites are used for detection of emergency beacons, asynchronous communica- 
tion capability would 'be required. Geostationary satellites do not perceive 
Doppler shift as do polar-orbiting satellites; therefore, it is necessary for 
an emergency beacon to transmit its location to a geostationary satellite. 


CONCLUDING REMARKS 

The digital control portion for a 406-MHz emergency beacon has been 
designed, breadboarded, and tested. The hardware was designed to have a low 
parts count and to be simple, reliable, and inexpensive. The hardware and 
three major software routines (BCH encoding, Biphase-L transmission, and Jitter 
Delay) are generic to any 406-MHz beacon. Although the software was designed 
to use the User Protocol format, it can easily be modified to accommodate any 
existing or future message formats. 

The work described in this paper was performed in support of the SARSAT 
program at the NASA Lewis Research Center in cooperation with the NASA Goddard 
Space Flight Center. Questions and comments concerning the digital control 
design should be addressed to the NASA Lewis Research Center, Space Electron- 
ics Division. Questions and comments concerning the COSPAS/SARSAT program 
should be addressed to the NASA Goddard Space Flight Center. 
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TABLE I. - GENERAL 406-MHz MESSAGE FORMAT 


[From ref. 2.] 


Bit 

1 ocation 

Number 
of bits 

Message 

Additional information 

1-15 

15 

Bit synchronization 

15 "1" bits in all beacons 

16-24 

9 

Frame synchronization 

000101111 in all beacons 

25-85 

61 

Protected data field 

Bi ts 25 to 112 {or to 
optional 144) form the 
unique code in each 
beacon 

86-106 

21 

Error-correcting code 

107-112 

6 

National use or 
emergency code 

113-144 

32 

Long message data 
(opti onal ) 
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TABLE II. - UNIQUE DATA IN 406-MHz MESSAGE FOR MARITIME/LOCATOR PROTOCOL 


[From ref. 2.] 


Bi t 

location 

Number 
of bits 

Message 

Additional information 

25 

1 

Format flag 

"0 H for short message and 
"1" for long message format 

26 

1 

Protocol flag 

Set to "0 n for this format 

27-36 

10 

Country code 

Binary equivalent of 
appropriate 3-digit decimal 
number 

37-56 

20 

Maritime identifica- 
tion digit 


57-85 

29 

Latitude and longitude 

Shown in deg and min 

86-106 

21 

BCH error-correcting 
code 


107 

1 

National use or 
emergency code flag 

"0" for national use and 
"1" for emergency code 

108 

1 

Automanual activation 

"0" for manual activation 
and "l" for automatic 
acti vati on 

109-112 

4 

National use or 
emergency code 

Four user-settable bits for 
national use or for emer- 
gency codes 

113-144 

32 

Long message data 
(opti onal ) 

Optional data giving time 
and velocity of vessel 
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TABLE III. - UNIQUE DATA IN 406-MHz MESSAGE FOR 8 POSSIBLE USER PROTOCOLS 


[From ref. 2.] 


Bit 

1 ocati on 

Number 
of bits 

Message 

Additional information 

25 

1 

Format flag 

"0" for short message and 
"1" for long message format 

26 

1 

Protocol flag 

Set to "1" for this format 

27-36 

10 

Country code 

Binary equivalent of 
appropriate 3-digit decimal 
number 

37-39 

3 

User protocol 

Specifies orbitography, 
aviation, maritime, serial- 
ized or test format (plus 
three spare formats) 

40-83 

44 

Data 


84-85 

2 

Homing signal 

Specifies which auxiliary 
homing frequency is incor- 
porated in the beacon 

86-106 

21 

BCH error-correcting 
code 


107 

1 

National use or emer- 
gency code flag 

"0" for national use and 
"1" for emergency code 

108 

1 

Automanual activation 

"O'* for manual activation 
and "1" for automatic 
acti vati on 

109-112 

4 

National use or 
emergency code 

Four user-settable bits for 
national use or for emer- 
gency codes 

113-144 

32 

Long message data 
(opti onal ) 

Optional data giving lati- 
tude and longitude of 
beacon in deg and min 


TABLE IV. - INTERNATIONAL 
MARITIME ORGANIZATION 


(IMO) EMERGENCY CODES 


[From ref. 2.] 


Code 

Def i ni ti on 

0000 

Undesignated 

0001 

Fi re or expl osi on 

0010 

FI oodi ng 

0011 

Col 1 i si on 

0100 

Groundi ng 

0101 

Listing, in danger 


of capsizing 

0110 

Si nki ng 

0111 

Disabled and adrift 

1000 

Abandoning ship 

1001 

Undesignated 

1010 

1011 

1100 

1101 

1110 

nn 

Test 



TABLE V. - EMERGENCY CODES FOR NONMARITIME USERS 3 


[From ref. 2.] 


Bit 

Descri pti on 

109 

no 

m 

112 

No f i re, 0 , or f i re, 1 
No medical help, 0, or medical help, 1 
Not disabled, 0, or disabled, 1 
Spare, 0 


a Orbi tography , aviation, and others. 
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TABLE VI. - THREE TESTS PERFORMED AND ASCII 


TABLE VII. - COMMAND FORMAT FOR ENTERING 


VALUE DETERMINED 


LONGITUDE AND LATITUDE 


ASCII 
Val ue 

Test results 

Switch PROM 

Data PROM 

80C51 

0 

Failed 

Failed 

Failed 

1 



Failed 

Passed 

2 



Passed 

Failed 

3 



Passed 

Passed 

4 

Passed 

Failed 

Failed 

5 



Failed 

Passed 

6 



Passed 

Failed 

7 



Passed 

Passed 



E/W East or West 
Minutes longitude 
Degrees longitude 
N/S North or South 
Minutes latitude 
Degrees latitude 


TABLE VIII. - BCH (82,61) ENCODING ALGORITHM FOR THREE DATA BITS 


Operation 



Data 

bi t 













Code 

bi t 










0 

1 

2 ... 

58 

59 

60 

TB a 0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

Ini ti al i ze code word 

1 

0 

1 ... 

X 

X 

X 

X 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Rotate data word 

0 

1 

X ... 

X 

X 

1 

i X 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

D60 XOR C20 

0 

1 

X ... 

X 

X 

1 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Shi ft code word 

0 

1 

X ... 

X 

X 

1 

1 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Code word XOR 
pol ynomi al b 
Rotate data word 

0 

1 

X ... 

X 

X 

1 

! 1 

1 

1 

0 

0 

0 

1 

1 

1 

1 

0 

0 

1 

1 

0 

1 

1 

0 

1 

1 

0 

0 

1 

X 

X ... 

X 

1 

0 

1 

1 

1 

0 

0 

0 

1 

1 

1 

1 

0 

0 

1 

1 

0 

1 

1 

0 

1 

1 

0 

0 

D60 XOR C20 

1 

X 

X ... 

X 

1 

0 

0 

1 

1 

0 

0 

0 

1 

1 

1 

1 

0 

0 

1 

1 

0 

1 

1 

0 

1 

1 

0 

0 

Shift code word 

1 

X 

X ... 

X 

1 

0 

0 

0 

1 

1 
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FIGURE 1. - COSPAS/SARSAT 406-MHz DISTRESS BEACON COMPONENTS. 


FIGURE 2. - DATA ENCODING AND MODULATION SENSE (REF. 2). 
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FIGURE 3. - THREE-CHIP DESIGN FOR A06-MHZ EMERGENCY BEACON. 
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FIGURE A. - CONNECTION DIAGRAM OF 80C51 MICRO- 
CONTROLLER (REF. 3). DIAGRAM IS FOR PIN REF- 
ERENCE ONLY. PACKAGE SIZES ARE NOT TO SCALE. 
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FIGURE 5. - ARCHITECTURAL BLOCK DIAGRAM OF 80C51 MICROCONTROLLER (REF. 3). 
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FIGURE 6. - MAJOR MODULES AND INTERRUPT ROUTINE OF MAIN 
PROGRAM. 
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FIGURE 7, - BCH (127, 106) ENCODER. 


13 














FIGURE 8. - BLOCK DIAGRAM OF BCH (82. 61) ENCODING 
ALGORITHM. 
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FIGURE 9. - TRANSMISSION MODULE DELAY LOOPS FOR MAKING TIMING ADJUSTMENTS. 
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FIGURE 10. - JITTER DELAY MODULE. 


FIGURE 11. - JITTER DELAY MODULE ROUTINE FOR 
CREATING DELAY BETWEEN MESSAGE TRANSMISSIONS. 
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